The development of large-scale business applications today must address a variety of concerns. Among these concerns are concurrency management, transaction management, persistence, security, presentation, business logic. All of these concerns must be addressed within the framework of applications, hardware/software topologies, and workloads. Each software component within this framework may have several configuration parameters that must be set correctly for the system to work properly. An incorrect configuration can result in application failure or underperformance, both of which are costly to organizations.
Frameworks such as Java™ 2 Platform, Enterprise Edition (J2EE™) developed by Sun Microsystems are designed to simplify the process of configuring a system by supporting the separation of concerns. The application developer can, for the most part, focus on implementing the business logic aspect of an application; the application server on which the application is deployed handles much of the complexity of concurrency, transaction, and persistence management.
In this framework, the deployer, the individual who configures the application server to manage concurrency, transaction and persistence correctly and efficiently, plays a central role. Enterprise systems are quite complex and the deployer in charge of configuring such a system must deal with the following: 1) the interactions between the application itself and the data affect the configuration of the application server and the deployer is usually not supplied with sufficient documentation to deal with this; 2) hardware and software systems with which the application interacts can affect its deployment significantly; 3) the workload of the application can affect the configuration of the application server; 4) best practice guides and rule-based profiles are heuristics that cannot possibly cover the entire space of applications, hardware/software topologies, and workloads and they themselves may have been based on a faulty premise; and 5) configuration-based problems are often difficult and expensive to trace because, more often than not, when an application fails the assumption is made that the application itself is flawed and resources are expended to find the culprit, which is thought to be a program bug.
The sheer size and complexity of the configuration space make it very difficult to manage. This situation is further complicated when, as is usually the case, the deployer who sets the configuration is the not the same person who designed the system and is not a user of the system. More often than not, the deployer is configuring a legacy system. Without adequate tools at their disposal, deployers must configure application servers using a mixture of rule-of-thumb, intuition, and trial-and-error. For smaller systems, control theory offers an adequate method for determining configuration values through appropriate models of the software, but for large system topologies seen in practice, such as enterprise systems, it is difficult to derive an appropriate model of the system. Even if a model could be developed it is highly unlikely that the model would be extensible across other application deployments, therefore there is a need for a methodology for configuring large systems.
Referring to FIG. 1, there is shown a block diagram of a conventional topology for application server deployment, according to the prior art. The Web servers 103 and 105 direct requests from the Internet 101 to the application servers 120 and 121. The application servers 120 and 121 are connected to a back-end database 150 where enterprise data are persisted.
Referring to FIG. 2, there is shown a block diagram of the structure of a J2EE-based application server, according to the known art. The application server 120 for this system is generally written in Java, and therefore, the entire system executes in one or more Java Virtual Machines (JVM) 260. As stated earlier, J2EE supports the separation of concerns; therefore the application server 120 is partitioned with respect to presentation, business logic, and data layers. The Web container 230 corresponds to the presentation layer. It manages interactions with the Web server 103. Browser requests are routed through the Web server 103 to the Web container 230, where either a static HTML page is returned or the execution of a Java Server Page (JSP) or servlet is launched. The JSP or servlet may in turn interact with the business logic layer, and ultimately, synthesizes the HTML returned to the user. The Web container 230 determines the concurrency of the servlets by controlling how many threads may execute at a time.
The Enterprise JavaBeans (EJB) container 235 corresponds to the business logic layer. The EJB container 235 manages the creation and execution of the Enterprise Java Beans deployed on the server 120. Furthermore, it controls the transactional behavior of the EJBs, their concurrency, and their caching. It also controls the interactions of the EJBs with the data source 240, which corresponds to the data layer. A data source 240 is an abstraction of a database. IT departments manage connections to a database 150 in a connection pool to reduce the expense involved in creating new connections. When an EJB no longer requires a connection to a database, rather than closing the connection, it returns the connection to the pool for later reuse. Furthermore, the data source 240 maintains a statement cache that is used to reduce the cost of processing frequently executed Structured Query Language (SQL) requests.